Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Backport release-3_22] Fix lots of georeferencer issues #47276

Merged
merged 47 commits into from
Feb 14, 2022

Conversation

qgis-bot
Copy link
Collaborator

@qgis-bot qgis-bot commented Feb 9, 2022

Backport #47141
Authored by: @nyalldawson

destination coordinates, and whether they are in pixels/map coordinates

And make some TODO notes flagging errors identified along the way
… issues when a second raster is loaded into the georeferencer
…points must ALWAYS be in source layer coordinates
raster file name for these and not the output raster file name

The GCPs relate specifically to the ORIGINAL image, not the warped
output exported after georeferencing. If we use the output file
name for the .points file then when THIS georeferenced output is
loaded into the georeferencer we get misleading location of
source GCP points, as the pixel coordinates are from the ORIGINAL
image, not the warped one.
from class which stores graphical item representing point
This is too fragile, there's too many different situations which
should lead us to invalidate the cached point which are not
being caught.
points instead of always using source pixel row/columns

The "always use pixels" approach does not work well when a source
image already has some georeferencing information attached.

Also add tests for this, and fix loading of "enabled" status for
points when loading points from a file
enabled

And partially fix this functionality when using an already
georeferenced image (not fully)
@github-actions github-actions bot added this to the 3.22.4 milestone Feb 9, 2022
(cherry picked from commit 74d7e13)
points don't move on canvas when edited in list

(cherry picked from commit ca2dbef)
points in table are always updated to reflect actual target CRS
whenever it is changed

(cherry picked from commit 15d7c8a)
(cherry picked from commit 610a0a6)
(cherry picked from commit a2bb366)
georeferenced, assume the source points are in the
raster's IF there's no explicit crs information in the .points file

(cherry picked from commit 8a12a0b)
(cherry picked from commit a39ed7b)
set CRS of destination to match the georeference target CRS

(cherry picked from commit 90c1325)
(cherry picked from commit 93564e0)
Helps clarify for users exactly what CRS these destination coordinates
are in

(cherry picked from commit 622c120)
@nyalldawson
Copy link
Collaborator

Also includes #47279

Copy link
Contributor

@nirvn nirvn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me. IMHO well worth backporting.

@nyalldawson nyalldawson merged commit bdd25ba into release-3_22 Feb 14, 2022
@nyalldawson nyalldawson deleted the backport-47141-to-release-3_22 branch February 14, 2022 04:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants